Network interface device

ABSTRACT

A network interface device is provided in a first device. The network interface device comprises an interface configured to receive a first input from a network. The network interface device also has at least one processor configured to provide an output in dependence on contents of the first input and provenance information which uniquely identifies the network interface device, the output being output via the interface to the network.

FIELD

Some embodiments relate to a network interface device, a method andsystem.

BACKGROUND

Network interface devices NIDs, sometimes referred to as NICs, areprovided in devices to allow the devices to output and/or receive data,often in the form of packets. The data in packets may be passed throughseveral devices, sometimes being manipulated on the way before beingprovided to an ultimate destination.

SUMMARY

According to an aspect, there is provided a network interface device ina first device, said network interface device comprising: an interfaceconfigured to receive a first input from a network; and at least oneprocessor configured to provide an output in dependence on contents ofsaid first input and provenance information which uniquely identifiesthe network interface device, said output being output via saidinterface to said network.

The first input may comprise provenance information of at least onenetwork interface device from which said first input has been receivedvia said network.

The first input may comprise at least one packet or at least one frame.

The output may comprises a digest.

The digest may be a digest of data comprising at least one of:

-   -   a digest of payload data in said first input;    -   a digest of payload data in said output;    -   a digest of application level objects;    -   a digest of application level data units; and    -   a digest of storage packet data units.

The digest may comprise a digest of provenance information for aplurality of network interface devices.

The digest may be provided in at least one packet or frame.

The digest may be appended as metadata to at least one packet or frame.

The output may comprise at least one packet or frame of data.

The output may comprise at least a part of at least one packet or frameof said first input with said provenance information.

The provenance information may be provided in a payload of at least onepacket or frame of data of said output.

The provenance information may be provided as metadata.

The provenance information may be provided in a field in one or moreoutput packets or frames of said output.

The provenance information may be appended to one or more output packetsor frames in said output.

The provenance information may be used to perform a hash function on atleast part of said data of a packet.

The output may comprise provenance information associated with one ormore network interface devices from which said first input was received.

The interface may be configured to receive a plurality of inputs eachhaving respective provenance information, said inputs being combined,said at least one processor being configured to provide an outputcomprising at least a part of provenance information associated witheach of said plurality of inputs.

The at least one processor may be configured to provide time stampinformation in said output.

The provenance information may comprise at least one of:

-   -   an identifier of said network interface device;    -   a unique serial number of said network interface device;    -   an identifier of a location of said network interface device;    -   an identifier of said first device;    -   an identifier of a domain with which the network interface        device is associated; and    -   a signature using a security key of said network interface        device.

The network interface device may comprise at least one memory configuredto store one or more rules, said at least one processor being configuredto apply said rules to at least one of said input and said output, atleast one rule using provenance information associated with at least oneof said network interface device and a further device.

At least one of said one or more rules may be configured to causeprovenance information to be stored to one or more applications.

At least one of said one or more rules may be configured to cause datafrom one or more applications to be output with provenance informationassociated with at least one of said network interface device and afurther device.

The at least one of said one or more rules may be configured to generatean alert in response to one or more conditions relation to provenanceinformation associated with at least one of said network interfacedevice and a further device.

According to another aspect, there is provided a system comprising: atleast one data store configured to store at least a part of outputs froma plurality of different network interface devices, said outputscomprising provenance information associated with the respectivedifferent network interface devices; and at least one processorconfigured to analyze said provenance information.

The at least one processor may be configured to determine if one or moreconditions associated with said provenance information have met.

According to another aspect, there is provided a method comprisingreceiving a first input from a network at an interface of a networkinterface device in a first device; and providing an output to saidnetwork via said interface in dependence on contents of said first inputand provenance information which uniquely identifies the networkinterface device.

The first input may comprise provenance information of at least onenetwork interface device from which said first input has been receivedvia said network.

The first input may comprise at least one packet or at least one frame.

The output may comprises a digest.

The digest may be a digest of data comprising at least one of:

-   -   a digest of payload data in said first input;    -   a digest of payload data in said output;    -   a digest of application level objects;    -   a digest of application level data units; and    -   a digest of storage packet data units.

The digest may comprise a digest of provenance information for aplurality of network interface devices.

The digest may be provided in at least one packet or frame.

The digest may be appended as metadata to at least one packet or frame.

The output may comprise at least one packet or frame of data.

The output may comprise at least a part of at least one packet or frameof said first input with said provenance information.

The provenance information may be provided in a payload of at least onepacket or frame of data of said output.

The provenance information may be provided as metadata.

The provenance information may be provided in a field in one or moreoutput packets or frames of said output.

The provenance information may be appended to one or more output packetsor frames in said output.

The provenance information may be used to perform a hash function on atleast part of said data of a packet.

The output may comprise provenance information associated with one ormore network interface devices from which said first input was received.

The method may comprise receiving a plurality of inputs each havingrespective provenance information, combining said inputs, and providingan output comprising at least a part of provenance informationassociated with each of said plurality of inputs.

The method may comprising providing time stamp information in saidoutput.

The provenance information may comprise at least one of:

-   -   an identifier of said network interface device;    -   a unique serial number of said network interface device;    -   an identifier of a location of said network interface device;    -   an identifier of said first device;    -   an identifier of a domain with which the network interface        device is associated; and    -   a signature using a security key of said network interface        device.

The method may comprise applying rules to at least one of said input andsaid output, at least one rule using provenance information associatedwith at least one of said network interface device and a further device.

At least one of said one or more rules may be configured to causeprovenance information to be stored to one or more applications.

At least one of said one or more rules may be configured to cause datafrom one or more applications to be output with provenance informationassociated with at least one of said network interface device and afurther device.

The at least one of said one or more rules may be configured to generatean alert in response to one or more conditions relation to provenanceinformation associated with at least one of said network interfacedevice and a further device.

A computer program comprising program code means adapted to perform theherein described methods may also be provided. In accordance withfurther embodiments apparatus and/or computer program product that canbe embodied on a computer readable medium for providing at least one ofthe above methods is provided.

In the above, many different embodiments have been described. It shouldbe appreciated that further embodiments may be provided by thecombination of any two or more of the embodiments described above.

Various other aspects and further embodiments are also described in thefollowing detailed description of examples embodying the invention andin the attached claims.

BRIEF DESCRIPTION OF DRAWINGS

Some embodiments will now be described by way of example only withreference to the accompanying Figures in which:

FIG. 1 shows a first example architecture in which embodiments may beprovided;

FIG. 2 shows a second example architecture in which embodiments may beprovided;

FIG. 3 shows a third example architecture in which embodiments may beprovided;

FIG. 4 shows an example network interface device;

FIG. 5 shows an analytics system;

FIG. 6 shows a method of an embodiment;

FIG. 7 shows a device having a network interface device; and

FIG. 8 shows some examples of outputs from a network interface device

DETAILED DESCRIPTION OF EMBODIMENTS

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofa particular application. Various modifications to the disclosedembodiments will be readily apparent to those skilled in the art.

The general principles defined herein may be applied to otherembodiments and applications without departing from the spirit and scopeof the present invention. Thus, the present invention is not intended tobe limited to the embodiments shown, but is to be accorded the widestscope consistent with the principles and features disclosed herein.

Reference is made to FIG. 1 which schematically shows a first examplearchitecture in which some embodiments may be provided. The examplearchitecture has a first device A which is referenced 100, a seconddevice B which is referenced 104, a third device C referenced 105, and afourth device D referenced 101. Each device has a respective networkinterface device NID 103. In the example architecture, a network 102 isprovided which allows the various devices to communicate. In theexample, the first device A 100 is configured to receive messages fromthe network and output messages onto the network. The fourth device D isconfigured to receive messages from the network and output messages ontothe network via the first device A. In some embodiments, the firstdevice A and the fourth device D may be part of a network such as aninternal company network or the like.

A packet may be received at the second device B from the third device C,via the network. The received packet will have provenance information ofthe NID of the third device. The NID of the second device will modifythe packet at least to add in the provenance information of the NID ofthe second device. The modified packet is then provided to the firstdevice via the network. The NID of the first device will modify thepacket at least to add in the provenance information of the NID of thefirst device. That further modified packet may then be provided to thefourth device. The packet which is provided to the fourth device willhave provenance information of each of the NIDs that the packet haspassed through. This provides a digest. The form of this digest or formof that data will be described in more detail later.

In this example embodiment, four devices with respective NIDs are shown.However, it should be appreciated that this is by way of example onlyand there may be more or less than four devices.

An analytics function 120 is provided. The function is configured toreceive data from either or both of the first and fourth devices, inthis example embodiment.

In some embodiments, at least the digest of the packet is provided tothe analytics function.

Reference is made to FIG. 2 which shows another example architecture inwhich embodiments may be used. In this example a first device 204 is ina first location, a second device 206 is in a second. The first andsecond locations may be different countries, for example. The firstdevice and second device each have a NID 208. The first and seconddevices are configured to communicate via a link 214. A further device208 is configured to communicate with the first and second device via anetwork 202. This communication is referenced 212. The further devicehas a NID.

As with the arrangement shown in FIG. 1, each time a packet is processedby a NID, provenance information of that NID is added to the packet toprovide a digest.

An analytics function 220 is provided and receives data via the network.

Reference is made to FIG. 3 which shows another example architecture inwhich embodiments may be provided. The architecture shows by way ofexample three different devices 300, device 1, device 2, and device 3.Each device has a respective NID 302. In this scenario, the first deviceis configured to provide data to the second device which in turn isconfigured to provide data to the third device. The third device isconfigured to provide an output to an analytics function 310.

As with the arrangement shown in FIG. 1, each time a packet is processedby a NID, provenance information of that NID is added to the packet toprovide a digest.

In embodiments, provenance information is added to the data each time itpasses through a NID. That provenance information will indicate that thedata has been received by a particular NID.

In some embodiments, a digest is provided which will include provenanceinformation for each NID that the data has passed through.

Optionally, the digest will provide order information to indicate theorder in which the data passed through the NIDs. This information may beprovided by the order of the provenance information within the digestand/or by using time stamp information.

-   -   The digest may alternatively or additionally be generated at an        analytics function.

Reference is made to FIG. 4 which shows a NID 410 of an embodiment. TheNID has an interface 402 which is configured to receive packets whichare to be output by the NID via that interface 402. For clarity an inputinstance of the interface and an output instance of the interface isshown but in practice there is a common interface for input data andoutput data. Other embodiments may of course have separate input andoutput interfaces.

The various blocks shown in FIG. 4 represent functions provided in theNID. The data path in the NID implement a chain of micro engines whichparse, classify, match then perform an action for each ingress/egressframe. This will be discussed in more detail later.

Schematically, the so-called normal processing of the packet takes placein part 401 of the NID. It should be appreciated that the representationof the NID shown in FIG. 4 represents the functions which are performedby the NID. One or more of the functions shows in FIG. 4 may beperformed by computer software running on hardware, with program codestored in memory. One or more functions may alternatively oradditionally be performed by hardware circuitry.

The processing which takes place in part 401 will now be described. Atleast part of function 401 may be performed in a reconfigurable logicdevice, such as an FPGA, an ASIC or the like. Part 401 comprises apacket inspector 404, a matching engine 407 and a packet filter 408. Adata store 400 includes rules and corresponding actions that are to beperformed.

The rules may be simple rules or more complex rules. For example a rulemay define one or more of a black list of flows which are not permitted,a white list of flows of permitted flows, and one or more limits such asconnection rate limits, bandwidth limits and packets. The rules maydefine the actions to be taken. For example a packet may be dropped orallowed to be delivered to its destination. Some rules may be dependenton the provenance information. Alternatively or additionally, an eventmay be generated and output on a control channel. Events may be sentseparately to the captured packets on the control channel. In someembodiments, events may be considered as another form of meta-data.

The packet filter may perform an action specified in the data storewhich corresponds to the rule which has been triggered.

In order to perform rules that relate to limits such as number ofpackets from a particular destination or a total number of packets or anumber of packets from a particular NID, the matching engine isconfigured to maintain state sufficient to allow the matching engine toperform such rules. The matching engine could be configured to store thestate at the data store. For example, if a rule causes the matchingengine to monitor the total number of packets, the matching engine wouldmaintain state identifying the total number of packets and update thatstate on receiving new packets. This would, for example, allow thematching engine to identify when a predetermined cap has been reachedand to, in response, perform a corresponding action identified in thedata store.

The rules that are to be enforced are written to data store.

The packet inspector 404 is arranged to parse incoming packets receivedover interface 402 so as to enable the relevant rules for each packet tobe identified in the data store 400. Rules could be selected from datastore 400 on the basis of any suitable information in the packetsincluding the provenance information. For example, different rules couldbe applied to flows directed to different endpoints. The rules maythemselves be programs expressed in a language such as BFP or regularexpressions.

It should be appreciated that more than one rule may be applied to agiven packet.

The packet inspector may be configured to perform a lookup into the datastore on the basis of given identifiers. For example, data representingthe source/destination of a packet may typically be included in theheader of a data packet. An indication that the packet passes the filtermay be provided to a packet encapsulation function as is discussedlater.

Reference is made to part 403. In this part, the packet which isreceived via the interface 402 is passed to a packet encapsulationfunction 414 which also receives metadata from the metadata function412. The metadata will be described in more detail later. Theencapsulation function also receives an output from the packet filterindicating if the packet passes the filter. In some embodiments, thepacket encapsulation function may receive the packet data from thepacket filter.

The packet encapsulation function will encapsulate the packet with themeta data. Optionally, this encapsulated packet is passed to anencryption function, which encrypts the packet or part of the packet.The output packet is passed to the interface.

It should be appreciated that in one modification, the encryption may beperformed before encapsulation. In some embodiments, the encryption andencapsulation may be performed together. The encryption is optional insome embodiments.

In alternative embodiments, instead of encryption, authentication ofmessages may be used.

In some embodiments, the metadata comprises network interface provenanceinformation. The metadata may comprise time stamp information whichgives the time at which the packet was received and/or is to be outputand/or when the provenance information was added.

However, there are alternative or additional examples of metadata thatmay be included. For example, metadata could include an event which wasgenerated as a result of the NID processing that packet.

The meta data may alternatively or additionally contain any state whichwas used in the processing which generated the event—such as aconnection rate, a timeout, an error condition and/or the like.

In some embodiments, the provenance information and/or metadata can beappended to the packet. In other embodiments an encapsulation is definedfor a structured object containing one or more fields which representmetadata and a packet contents field.

In some embodiments, the packet filter outputs the packet with theprovenance information which is then transmitted to the next device.

Alternatively or additionally a copy of the packet to which theprovenance information and/or metadata has been added is directed to ananalytics function. It should be appreciated that the digest may becreated by the analytics function in these embodiments.

In some embodiments, a summary or a digest of a plurality of packetswith the associated provenance information may instead be forwarded tothe analytics function.

In some embodiments, the digest may comprise a digest of payload data.

In some embodiments, the digest may comprise a digest of a storagepacket data unit PDU. It should be appreciated that many PDUs may becontained in a Layer 2 frame or span a layer 2 frame.

In some embodiments, the digest may comprise a digest of file objects.

In some embodiments, the digest of an application level object or dataunit may be provided.

It should be appreciated that the digest may be created by the analyticsfunction in alternate embodiments.

Some examples of outputs from a NID are shown in FIG. 8.

1. There is a header field, followed by a payload. Meta data isappended. This may be NID provenance information and optionally timestamp information.

2. There is a header field, followed by a payload. Meta data isappended—this may be time stamp information. This is then signed usingthe NID identifier.

3. There is a header field, followed by a payload. Meta data is insertedinto the payload. This may be NID provenance information and optionallytime stamp information.

4. There is a header field, followed by a digest of payload datafollowed by a digest of NID provenance information.

In some embodiments, the digest may be of payload data, a digest ofstorage PDU (note that many PDUs can be contained in a Layer2 frame orspan a layer2 frame) or a digest of an application level objects or dataunits.

In some embodiments, each time a message or packet passes through anetwork interface device, provenance information from that networkinterface device is provided. For example, in the context of thearrangement shown in FIG. 3, as the message is passed through each ofthe devices, provenance information from each of the network interfacedevices is added. Accordingly, a digest may be provided in that messagewhich will indicate the provenance of each of the network interfacedevices that the message has passed through. In some embodiments, thismay be provided along with time stamp information. In other embodiments,the order of the network interface device provenance information mayindicate the order in which the message has passed through the networkinterface devices.

The digest which is generated is provided to a respective analyticsfunction. The information provided by the may be used in any suitableway.

The provenance information may be provided in a field. This field may beadded to an end of the packet or inserted into the body of the packet.The provenance information may be provided by performing a hash functionusing the provenance information.

Provenance information may comprise information specific to the NID. Forexample, the information may be one or more of a unique NID ID,generated using a private key and/or public key. For example a signatureis provided, which may be generated using a per NID private key. Thatsignature may be verified using a NIDs public key. The provenanceinformation may comprise information relating to the physical locationof the NID. For example, the provenance information may comprise one ormore of an identity of a data centre, a network to which the NID and itsassociated device are a part, a geolocation, and provenance informationgenerated by the physical infrastructure such as the identity of aconnected data lake or storage pool. For example, the provenanceinformation may be a customer, end user or the like identity. In someembodiments a second private key is provided so that the provenance metadata can be signed twice, once to indicate the NID identity and oneagain to include the identity of the customer, data center, end-user orthe like.

In some embodiments, the provenance information may comprise time stampinformation, such as previously mentioned.

It should be appreciated that the provenance information may be made upof one or more different ones of the provenance information. For examplein one embodiment, a key specific to the NID may be used to sign one ormore other ones of provenance information mentioned previously.

In other embodiments, the provenance information may be concatenated ina field.

The provenance information may be provided in a header field in someembodiments.

In some embodiments, the NID may accumulate records to prepare a digest.This digest, as mentioned previously may have a copy of the data of themessage or just summary data.

In some embodiments, a digest of a frame is hashed using provenanceinformation associated with the NID. This may be for example using theidentity of the NID or a key associated with the NID.

The digest provided by a NID may have one or more of a frame number andtime stamp which is signed using the NID provenance information.

In some embodiments, the analytics function may collect digests against,for example, the NID identifier. This may be with the original messageor with a reference to the original message.

In some embodiments, a log may be generated at the analytics functionwith provenance for all NICs associated with given data.

Each NID may in some embodiments be configured to direct a copy of thepackets which it receives to a capture buffer which is part of theanalytics function. The system may be set up so that any packets whichare received by NID from a network and/or packets which are to be putonto the network by the NID are sent to the capture buffer. In someembodiments, one or more NIDs may only direct a copy of incoming packetsto the capture buffer, and/or one or more NIDs may only direct a copy ofoutgoing packets to the capture buffer and/or one or more NIDs maydirect a copy of incoming and outgoing packets to the capture buffer.Some or more of the packets may be replicated. Some or all of thecontent of a given packet may be replicated.

The analytical engine may be configured to generate the digests from anumber of different NIDs. It should be appreciated that the capturebuffers may be omitted in some embodiments and the data simply passed tothe analytical engine which has some data storage capacity. In thisscenario, the analytical engine would process the data substantially inreal time. However, it is preferred that there is a capture buffer asthis provides elastic storage as the quantity of data captured maydepend on the time frame over which the data is being captured and/orvolume of data. In some scenarios, it is desirable to have data for agiven time period to assist in determining if a feature is normal or ifan alert should be generated. The data in the capture buffers may thusbe stored for at least the given time period. The packets will also bedirected by the NID to their intended destination via, for example viathe network. In embodiments, the normal processing of a packet by a NIDis unaffected by the directing of the copy to the capture buffer.

In some embodiments, the analytics function may uses digests to track asame frame which has been observed at various points in a network tocollate all provenance information for that frame.

The analytics function is one example of a function which can use theprovenance information. For example the analytics may be configured togenerate alerts.

In some embodiments, an alert may be generated in response to one ormore particular rule(s) being violated. There may be a plurality ofdifferent rules which have respective different conditions which causean alert to be generated. An alert may provide information whichindicates the reason for the generation of the alert.

An alert may be generated when the digest indicates that a network flowhas come via a particular device which is contrary to the one or morerules. For example one or more NID is determined to be carrying networkflows from outside an expected domain.

An alert may be generated when a message is determined to have beenrouted over a network which is outside the expected security domain.

An alert may be generated when a service level agreement has beendetermined to be violated.

In some embodiments, data from a plurality of different sources may becombined. The data from different sources may be stored in a database.

In some embodiments, the NIC may combine the provenance information forall frames received. This combined information may be added to one ormore or all output frames. This would ensure that for example the dataor output generated by an application (such as a map/reduce node) istagged with at least the provenance of all the inputs to thecalculation. By the hardware by storing and manipulating thisinformation, it is possible to ensure that provenance is not lostthrough the application/computation layers at the node. For example onenode or device may receive a plurality of packets from a plurality ofdifferent devices. Each packet may be tagged or associated with therespective provenance information. The node will use data from aplurality of packets from different devices to provide an output. Theoutput will have the provenance information of the node as well as thatassociated with packets used in the determination of that output.

In some embodiments, such a combination process may reduce theprovenance operation for example to a union operator, rather than aconcatenation operation. For example not all provenance informationwould be required to be combined. For example time stamp informationmight not be required but location of the sources of the data may berequired.

Such a combination or reduction operation depends on the application andmay prevents the provenance information growing every larger. Forexample, if every packet received at a node contains the {sourcedata-centre location and a time-stamp} then included in the outputprovenance information which is included on every frame output by thatnode could be the set of all data sources, such as data-lake identity orcountries, which may have provided an input to the computation performedat that node.

In some embodiments, the data may be stored with at least a part of theNID provenance information. The provenance information can thus be usedto preserve the origin of the data.

The provenance information can be used to prevent the writing of datafrom a particular source. The database may be configured to only writedata to the database from a selected set of NIDs. Alternatively oradditionally, the database may be configured to have a blacklist of NIDsand will only write data for NIDs not on the black list.

In some embodiments, data from a plurality of sources may be combined toform new data. The provenance data may be used to prevent theunauthorized combination of data or to retain information about therespective sources of the data.

There may be bars on combining data based on location, security level,compatibility of the data and/or any other requirement. The provenanceinformation may be used to ensure compliance with one or more theserequirements.

In content delivery networks, the use of the provenance information mayprovide improved security of information because origin of data can bedetermined

Where the provenance information comprises time stamp information, thismay be used by any analytics function to monitor the performance of anetwork or networks. The provenance information and time stampinformation may be used, for example to determine latency.

In some embodiments, the provenance information may be used for securitymonitoring. This may be in for example a data centre or the like.

In some embodiments, the provenance information may be used for anomalydetection and/or detection of threats.

In some embodiments, the provenance information may be used for networkplanning/learning. For example the analytics may see new data paths.

In some embodiments, the provenance information may be used to preventdata from being moved from a particular location and/or control wherethe data is output to. Rules may be set up based on the provenanceinformation to prevent this

In some embodiments, the provenance information may be used to reject oraccept data based on provenance. This may be performed in one or moreNIDs. The NID may be able to reject data based on the identity of one ormore NIDs in the received message.

Some embodiments may be used where security in a network or transactionsacross networks is desired. Some embodiments may be used in internalnetworks across distributed sites

For example, different ones of the network interface devices may belocated in different countries. There may be a bar on certain types ofdata being passed from one country to another. The analytics device isable to determine if the integrity of the data has been maintained bydetermining that data has not passed through a barred country.

Networking protocols have evolved to support the provision of anentirely virtualized LAN (local area network). For example tunnelingprotocols such as VXLAN (virtual extensible LAN) and NVGRE (networkvirtualization using generic routing encapsulation) provide a consumerwith an entirely virtualized network. The virtualized network maycomprise one or more of virtual switches, hosts, network appliances andstorage pools. For a service or cloud provider the cloud based platformcan be provisioned and resource balanced over large pools of physicalinfra-structure. This can provide economies of scale and access totechnologies which engender high efficiencies or access to cheap energysources. Service (cloud) providers may automate the provision of theunderlying cloud infrastructure. This may allow entire networks,applications and data to be instantiated, replicated and migratedseamlessly between different parts of the physical infrastructure. Thismay be done such that this is transparent to the consumer or client.

However in some situations, this flexibility to migrate betweendifferent parts of the physical infrastructure may be disadvantageous.For example an application whose components are supported by physicallyseparated parts of the cloud infrastructure may suffer performancepenalties. Another example is where data is required to reside within ageographic region for legal or security reasons and the cloudinfrastructure is provided by resources in two or more geographicregions or countries.

Whilst a cloud service provider may offer guarantees on physicallocality on the particular infrastructure resources supporting aparticular application, these guarantees may be inadvertently breached.Since the consumer or client is presented with an entirely virtualizedinfra-structure, currently the consumer is unable to verify or enforcethese guarantees. Since the cloud service provider manages its serviceprovision through mobility in order to achieve desired levels ofoperational efficiency there is always the possibility that anautomation or human operator error could cause a computer container (orVM virtual machine) or a storage component to be migrated to a part ofthe infrastructure which does not satisfy the geographic location, forexample.

It may be that a virtual network segment could inadvertently be carriedover an inappropriate territory even if the final geographic locationsatisfies the location requirements.

Alternatively or additionally a virtual network segment may be carriedover physical infrastructure which does not match for example a SLA(service level agreement). A SLA may specify a certain link speed, aparticular service level, a minimum service level, a particularapplication response time and/or other criteria. A network link orvirtual network lane which is supposed to be running at a certain linkspeed may in fact be misconfigured or faulty.

In some embodiments, analysis of provenance information may be used toenforce/verify that SLA requirements have been met, for example in termsof location of data, response times of applications and/or permittedcombinations of data.

This analysis of provenance information may be provided by an analyticsengine and/or in a NID of a device and/or in a device with a NID.

It is envisaged that operational efficiency demands in the future maymean that physical infrastructure workloads are required to be migratedover different geographic regions as a matter of course. For examplerenewable energy sources are not always dependable or fluctuateaccording to weather patterns or time.

Some embodiment may allow the use of virtualized infrastructure whilstproviding a more reliable guarantee to a customer/consumer as to thedomain (for example geographical location) in which the virtualizedinfrastructure resides. This may be without revealing details of theunderlying physical infrastructure. In some embodiments, this may beachieved by providing provenance information. In particular, becauseprovenance information is added every time a packet passes through adevice, the adherence to a particular requirement or requirements can bedemonstrated.

The devices of any of the previous architectures may be computerdevices. The computer devices may comprise one or more computers and/orone or more servers and/or any suitable one or more client devices.

In some embodiments, the device may comprise a virtualized device.

In some embodiments, the device may instead be considered to be aninfrastructure. That infrastructure may be made up of a plurality ofphysical devices which support a plurality of virtualized devices.

Some embodiments may be used in any scenario where there is at least afirst physical infrastructure and a second physical infrastructure andwhere one or more requirements of a user is not satisfied by one of theinfrastructure and migration of virtual resources between the physicalinfrastructures is possible. The first and second infrastructure may beseparately located or located in a common location. The first and secondinfrastructure may be part of a common infrastructure or physicallydifferent infrastructure.

Some embodiments may be used in any scenario where there is at least afirst device and a second device and where one or more requirements of auser is not satisfied by one of the devices and transfer of data betweenthe devices is possible. The first and second devices may be separatelylocated or located in a common location. The first and second devicesmay be part of a common network or physically different networks.

Alternatively or additionally, the different infrastructures or devicesmay be in one or more of different data centers, domains and territory.

Some embodiments may be used in the context of the so-called cloudarchitecture. It should be appreciated that in other embodiments anyother suitable infrastructure may be used. For example, theinfrastructure may comprise one or more of a secure infrastructure, aremote infrastructure, data center infrastructure; infrastructureprovided as a service or any other suitable infrastructure. The secureinfrastructure may for example be a control network for an airport.

In the previously described embodiments, reference has been made tonetwork interface device NID. This is sometimes referred to as a NIC. Anetwork interface device could be provided in any suitable form,including as a peripheral device or integrated with hardware of a hostdata processing device. A network interface device provides an interfaceto the network for use by its associated data processing device or thelike.

The NIC or NID may logically be a component of a server in someembodiments.

The NID may be considered to be a physically separate and distinct pieceof hardware and logically distinct network entity.

In some embodiments, the NID may be implemented by a hardware device. Inother embodiments, the NID may be implemented by a hardware device alongwith software in an operating system for example.

The component such as the NID or the like may comprise at least oneprocessor and at least one memory.

In some embodiments, the NID may be programmed at manufacture or at atrusted customer location to securely store provenance information orinformation used to generate provenance information. In someembodiments, at least some of the stored provenance information may beunique to the particular component.

The device programming at manufacture may be implemented so as to notreveal the final key stored within the device, for example by themodification of a key provided to the device by the device itself usinga source of random entropy. Techniques such as this would allow a deviceprivate key to be generated in a secure manner.

The relevant key should be stored securely as each NID or the likeallows. This may be by means of nonvolatile memory.

Generally the NIC will have some processing capability provided by atleast one processing device. The processing device may be any suitableprocessing device and may for example be an FPGA (Field ProgrammableGate Array), an application processor, a micro-engine, a networkprocessing unit, a sequencer or the like. The NIC may have some memorycapability which may for example be provided in the FPGA or by any othersuitable memory.

In the previously described embodiments, reference has been made tonetwork interface device. However, embodiments may be used with anyother suitable physical component. By way of example only, that physicalcomponent may alternatively or additionally comprise a hypervisor, aswitch, a load balancer, a firewall and/or the like.

Some embodiments may be used where at least some virtualization issupported so that the physical components supporting a particularservice, application, database and/or the like can change. Otherembodiments may be used in non-virtualized implementations.

It should be appreciated that the source of packets may be any suitablesource of packets. A server is one example of such a source. Anotherexample of a source may be a switch or a device connected to thenetwork. The packets may be generated inside an internal system and/orbe received from an external system. Each entity which sends packets isusually also able to receive packets. In embodiments, each entity whichreceives and/or transmits packets is associated with a NID. An entitymay share a NID with at least one entity, have its own NID or have morethan one NID.

The network may be an internal network, an external network or both.

Reference is made to FIG. 6 which schematically shows a method carriedout in the NIC.

In step S1, a packet is received from another device.

In this example, the packet may be checked in step S2 to determine ifany rule is to be applied to the packet. In some embodiments, the rulemay relate to provenance information, such as previously described.

The NID will in step S3 prepare the provenance information. For examplethis may be in the form of metadata and also include a time stamp.

In step S4, the packet data is encapsulated with the metadata to form apacket.

In step S5, this packet is output by the NID.

It should be appreciated that this method may be modified to support anyof the previously described embodiments.

Reference is made to FIG. 5 which shows schematically shows thefunctionality associated with one example of an analytics function. Thismay be provided by an analytics system. The analytics system maycomprise one or more apparatus.

The analytics system may have one or more processors or processingfunctions. For example, an analytical engine may be provided. Theanalytical engine is configured to receive data, such as previouslydiscussed from one or more NICs. This will include at least provenanceinformation. This data is represented by reference number 231.

This data may be analyzed as it is received and/or stored in a databasefor later analysis.

The analytical engine may be configured to carry out any of thepreviously discussed analysis.

For example, the analytical engine learn what constitutes normalbehavior of the network and when to raise an alert.

In some embodiments, information may be provided to a user interface209. For example the user interface may be in the form of a graphicaldisplay.

In some embodiments, one or more alerts or information may be providedto another computer implemented process for control.

In some embodiments, the analytical engine may be configured toimplement a machine learning function or computer program. The machinelearning function may be configured to recognize for example cascadedtransactions. The machine learning function may be configured to extractfeatures which are considered to be normal. The analytical engine useswhat is considered to be normal to determine when there is abnormalbehavior.

Some embodiments may use a machine learning algorithm such as a deeplearning algorithm. The algorithm uses layers of processing units wheresuccessive layers use the output from the previous layer as an input.The analysis may involve classification and pattern analysis. Forexample data associated with a flow received by the analytical enginemay be or attempted to be categorized as belonging to or satisfying aparticular policy using the provenance information. Any flow which doesnot belong to any policy may cause an alert to be generated and outputby the user interface.

In some embodiments, the machine learning algorithm may be is configuredto define a new policy for that flow.

It should be appreciated that any suitable technique may be used toperform analysis. For example correlation of different packets or datamay be performed.

The analytical engine may be provided with an AI or deep learning or anyother suitable learning algorithm to learn what constitutes normalbehavior.

In some embodiments, the analytical engine may be configured to receiveprovenance data associated with a large number of NIDs. For example thenumber of NIDs may be in the thousands.

In some embodiments a NID will have a secure connection with acontroller 208 in a trust domain. This allows the rules which areapplied by a NID to be updated. These rules may be relate to provenancesuch as previously discussed. The controller may 208 may receive anoutput from the analytical engine 206 which is used by the controller toset up or modify the rules of a NID. In some embodiments, the functionof the controller is provided by the analytical engine and can beregarded as being part of the analytical engine.

Some embodiments may have provenance rules provided at the NID andenforced at the NID. For example the provenance rules may comprise oneor more of:

storing the union of the provenance of all frames received for flows toa given application;

ensuring that the frames which are output by that application onto thenetwork are tagged with at least the union of the input data and ensurethat this output provenance is within the rules stored at the NIC forthis application; and

support a control plane (for example a connection to the controller)which allows provenance rules to be set, inspected and receive alertswhen violations have occurred.

Reference is made to FIG. 7 which schematically shows an example device700 with a NID 702 which is configured to execute at least some of thefirmware and at least one memory 106 which is configured to store atleast some of the firmware code.

The device 700 has a device driver 703 for the NIC 4, in someembodiments. The device may have an operating system OS part 712operating at a higher level of privilege to a user level part 714. Thedevice driver is provided in the OS part. The OS part may comprise oneor more processors 718. The OS part may comprise and/or have access toone or more memories 716.

The user level part may support one or more user level applications. Inthe example shown in FIG. 7, the user level part supports a firstapplication 720 and a second application 722. In some embodiments, theNIC may provenance data to application processing layers—either in theNIC or to one or more of the applications.

The applicant hereby discloses in isolation each individual featuredescribed herein and any combination of two or more such features, tothe extent that such features or combinations are capable of beingcarried out based on the present specification as a whole in the lightof the common general knowledge of a person skilled in the art,irrespective of whether such features or combinations of features solveany problems disclosed herein, and without limitation to the scope ofthe claims. The applicant indicates that aspects of the presentinvention may consist of any such individual feature or combination offeatures. In view of the foregoing description it will be evident to aperson skilled in the art that various modifications may be made withinthe scope of the invention.

Network interface devices, sometimes referred to as NICs are provided indevices to allow the devices to output and/or receive data, often in theform of packets.

The complexity of processing on some NICs has increased substantially tothe point where entire applications may be executed on the NIC. Complexoperations such as capture, flow steering, telemetry, firewalling arebeing deployed on NICs.

Regardless of the complexity or otherwise of operations performed by aNIC, it is desired that the NIC be configured to only execute thefirmware or computer code which is intended.

The invention claimed is:
 1. A network interface device in a firstdevice, said network interface device comprising: an interfaceconfigured to receive a first input from a network; and at least oneprocessor configured to provide: an output in dependence on contents ofsaid first input; and provenance information which uniquely identifiesthe network interface device, said output being output via saidinterface to said network, wherein said output comprises a digest of aplurality of packets with the provenance information, the at least oneprocessor being configured to forward said digest with the provenanceinformation to an analytics function.
 2. The network interface device asclaimed in claim 1, wherein said first input comprises provenanceinformation of at least one network interface device from which saidfirst input has been received via said network.
 3. The network interfacedevice as claimed in claim 1, wherein said first input comprises atleast one packet or at least one frame.
 4. The network interface deviceas claimed in claim 1, wherein said provenance information is appendedto one or more output packets or frames in said output.
 5. The networkinterface device as claimed in claim 4, wherein said digest comprises adigest of provenance information associated with a plurality of networkinterface devices.
 6. The network interface device as claimed in claim4, wherein said digest is provided in at least one packet or frame. 7.The network interface device as claimed in claim 4, wherein said digestis appended as metadata to at least one packet or frame.
 8. The networkinterface device as claimed in claim 1, wherein said output comprises atleast one packet or frame of data.
 9. The network interface device asclaimed in claim 1, wherein said output comprises at least a part of atleast one packet or frame of said first input with said provenanceinformation.
 10. The network interface device as claimed in claim 1,wherein said provenance information is provided in a payload of at leastone packet or frame of data of said output.
 11. The network interfacedevice as claimed in claim 1, wherein said provenance information isprovided as metadata.
 12. The network interface device as claimed inclaim 1, wherein said provenance information is provided in a field inone or more output packets or frames of said output.
 13. The networkinterface device as claimed in claim 4, wherein said digest is a digestof data comprising at least one of: a digest of payload data in saidfirst input; a digest of payload data in said output; a digest ofapplication level objects; a digest of application level data units; anda digest of storage packet data units.
 14. The network interface deviceas claimed in claim 1, wherein said provenance information is used toperform a hash function on at least part of data of a packet.
 15. Thenetwork interface device as claimed in claim 1, wherein said outputcomprises provenance information associated with one or more networkinterface devices from which said first input was received.
 16. Thenetwork interface device as claimed in claim 1, wherein said interfaceis configured to receive a plurality of inputs each having respectiveprovenance information, said inputs being combined, said at least oneprocessor being configured to provide an output comprising at least apart of provenance information associated with each of said plurality ofinputs.
 17. The network interface device as claimed in claim 1, whereinsaid at least one processor is configured to provide time stampinformation in said output.
 18. The network interface device as claimedin claim 1, wherein said provenance information comprises at least oneof: an identifier of said network interface device; a unique serialnumber of said network interface device; an identifier of a location ofsaid network interface device; an identifier of said first device; anidentifier of a domain with which the network interface device isassociated; and a signature using a security key of said networkinterface device.
 19. The network interface device as claimed in claim1, comprising at least one memory configured to store one or more rules,said at least one processor being configured to apply said rules to atleast one of said input and said output, at least one rule usingprovenance information associated with at least one of said networkinterface device and a further device.
 20. The network interface deviceas claimed in claim 19, wherein at least one of said one or more rulesis configured to cause provenance information to be stored to one ormore applications.
 21. The network interface device as claimed in claim19, wherein at least one of said one or more rules is configured tocause data from one or more applications to be output with provenanceinformation associated with at least one of said network interfacedevice and a further device.
 22. The network interface device as claimedin claim 19, wherein at least one of said one or more rules isconfigured to generate an alert in response to one or more conditionsrelation to provenance information associated with at least one of saidnetwork interface device and a further device.
 23. A method comprising:receiving a first input from a network at an interface of a networkinterface device in a first device; and the network interface deviceproviding an output to said network via said interface in dependence oncontents of said first input; the network interface device providingprovenance information which uniquely identifies the network interfacedevice, wherein said output comprises a digest of a plurality of packetswith the provenance information; and forwarding said digest with theprovenance information to an analytics function.